Skip to content

Remove type instabilities and allow general floating point types #121

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 19 commits into from
Apr 10, 2025
Merged

Remove type instabilities and allow general floating point types #121

merged 19 commits into from
Apr 10, 2025

Conversation

@JoshuaLampert
Copy link
Owner

@JoshuaLampert JoshuaLampert commented Apr 9, 2025 •
edited
Loading

There were several type instabilities. I tried to fight them as much as I could, but in some places it might be unavoidable (e.g., creating NodeSets from non-statically sized vectors). I also added some tests that the floating point type is preserved during interpolate and solve_stationary. It should cover most of the package, but maybe not everything.
I also decided to force floating point element types for NodeSets, which makes lives easier.

@JoshuaLampert JoshuaLampert marked this pull request as draft April 9, 2025 15:51
@JoshuaLampert
Copy link
Owner Author

JoshuaLampert commented Apr 10, 2025 •
edited
Loading

This is breaking because:

  1. random_hypersphere and random_hypersphere_boundary expect a Tuple as center now.
  2. The element type of NodeSets will always be converted to a floating point type as this makes more sense in an interpolation framework. A similar approach is also taken by the Meshes.jl/CoordRefSystem.jl framework.

github-actions[bot]
github-actions bot reviewed Apr 10, 2025
View reviewed changes
@JoshuaLampert JoshuaLampert marked this pull request as ready for review April 10, 2025 09:29
@codecov
Copy link

codecov bot commented Apr 10, 2025 •
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.66%. Comparing base (7002677) to head (4823e8d).
Report is 2 commits behind head on main.

Additional details and impacted files 
@@           Coverage Diff           @@
##             main     #121   +/-   ##
=======================================
  Coverage   98.65%   98.66%           
=======================================
  Files          46       46           
  Lines        1266     1269    +3     
=======================================
+ Hits         1249     1252    +3     
  Misses         17       17

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@JoshuaLampert
Copy link
Owner Author

JoshuaLampert commented Apr 10, 2025

Another instance of OrdinaryDiffEq.jl completely breaking Downgrade... I think that's because of SciML/OrdinaryDiffEq.jl#2567. The latest version of OrdinaryDiffEqDifferentiation.jl (v1.6.0) (which is installed because we don't require a compat of it) is not compatible with older versions of OrdinaryDiffEqNonlinearSolve.jl and OrdinaryDiffEqRosenbrock.jl and therefore we need the latest ones (v1.6 and v1.9 respectively).

@JoshuaLampert
Copy link
Owner Author

JoshuaLampert commented Apr 10, 2025 •
edited
Loading

Because of yet another wrongly set compat bound in the SciML ecosystem, we also need to drop support for DiffEqCallbacks.jl v3...

@JoshuaLampert JoshuaLampert merged commit 3918d25 into main Apr 10, 2025
17 checks passed
@JoshuaLampert JoshuaLampert deleted the performance branch April 10, 2025 11:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@github-actions github-actions[bot] github-actions[bot] left review comments

Assignees

No one assigned

Labels

breaking performance

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@JoshuaLampert